Hyper Text Markup Language (HTML) is a popular authoring language used to create documents on the World Wide Web (WWW). HTML forms are in widespread use on the Internet in order to receive input from users that visit a web site. HTML forms elements are a subset of the HTML specification. The complete specification for HTML forms is not recited here, but is incorporated by reference.
HTML forms can contain various input elements including the following:                text fields (represented in HTML as <input type=text>)        password fields (<input type=password>)        radio buttons (represented as <input type=radio>)        checkboxes (<input type=checkbox>)        buttons like submit, reset and button (<input type=submit>, <input type=reset>, <input type=button>)        select lists (<select> <option> </select>)        text areas (<input type=textarea>)        hidden fields (<input type=hidden>)        file field (<input type=file>)        
FIG. 1 shows a simple example HTML file containing a simple form with some of the elements shown above. FIG. 2 shows the same HTML form rendered in a modern browser. The input elements may have many different attributes. Usually, each of the input elements has a name that serves as a variable identifier. Collectively, the specific set of form fields in a particular form can be referred to as the “input fields” of that form. The set of names of the input fields of a particular form can be referred to as the “input field names” of that form. In the example shown in FIG. 1, the input field names are: firstname, smoker, location, id, submit.
Users provide input into these form elements on a web page. A user's input in some field in the browser effectively becomes the value associated with the name of that field when the form is submitted to a web server for processing. The specific user inputs into a specific form are referred to as the “input field values” or “submitted field values” or the “submitted form values”.
When an HTML form is submitted (e.g., by the user clicking on a <input type=submit> element or by causing the same effect as the pressing of a submit button using scripting language like Javascript or others), a Uniform Resource Locator (URL) on a HTTP server is accessed. The input field values in the HTML form are passed to the server using either a “GET” or “POST” method of passing these variables. The HTTP specification and the Common Gateway Interface (CGI) specification describe the manner in which the variables are delivered to the web server and then to the program that is executed as a result. In the example in FIG. 1, the method is POST and the URL that is accessed is HTTP://www.remoteserver.com/form.cgi.
The program on the server that receives the user input and performs some processing of the input and generation of a response is called a “CGI program”. The term CGI program used here does not imply any particular language (which could be Java, C, shell scripts, Perl, Python, ASP, Tcl/Tk etc) or any particular server hardware or HTTP server software.
The CGI program can be located at an arbitrary location referenced by an URL as specified in the <form> tag of the HTML page. The tag contains an ACTION attribute that specifies the URL of the CGI program. Typically, the CGI program is on the same web server as the HTML form. But this is not necessary and the CGI program can reside at an arbitrary URL. A CGI program that resides on a different web server from the HTML form is referred to as a “remote” CGI program. A CGI program that resides on the same web server as the HTML form is referred to as a “local” CGI program. The CGI program or CGI script can be a fully general program that is executed when a form submission is received. In order to write any arbitrary CGI program for any arbitrary form, it would require a human that is capable of writing the program and it would require this human to have knowledge of the form field elements and knowledge of what functionality the program is intended to have. One of the aspects of this invention is to eliminate the need for a human to write the CGI program. Thus, the CGI program is to be generated programmatically. In order to make this problem tractable, the CGI program cannot be expected to perform any arbitrary function. Instead, there is a super set of actions that this CGI program might perform. This superset can include performing some computation with the input field values to generate some dependent values, generation of a web page in response to the user, generation of various email messages which can contain some or all of the input field values or other content, storage of the submitted data in a database or other persistent store, triggering of change of state of the contents of a database or persistent store etc. These actions are described in more detail later. For any given form, the CGI program might perform some subset of the superset of actions. Thus, a specification is required that is the set of actions that the CGI program is expected to perform for a given form. These actions may or may not depend on the field elements of a given form. These actions may or may not depend on the field values entered by a given user in a given form.
CGI programs may be classified into the following types on the basis of the dependence of the actions performed by the CGI program on the specifics of the form field elements or the form field values.                Type A: This is a CGI program that does not require any a priori information of any of the specific input fields in the form. It performs the same function, regardless of the specific input fields in the form. By extension, it performs the same function regardless of the specific submitted field values in the form. An example of this type of CGI program would be a CGI program that simply takes all the input field names and submitted field values and saves it into a file and provides a fixed response to the submitter. In the example shown in FIG. 1, if the CGI program was type A, it might simply respond to the user with an HTML page containing the string “Thank you”. The program would respond in exactly the same way if the form was modified to include a few extra input fields, or if a completely different form had its ACTION URL pointing to this Type A CGI program.        Type B: This is a CGI program that does not require any a priori information of most of the specific input fields in the form, but does rely on the existence of certain agreed upon input field names to customize certain aspects of the behavior of the CGI program. The “agreement” is between the author of the form HTML who determines the fields and their names in the form and the author of the CGI program that expects to use certain field names to control its behavior. In the example in FIG. 1, the CGI program “form.cgi” may expect to see an input field name such as “emailto” in the form and uses the submitted field value associated with the “emailto” field to determine the email address to which to email all the submitted field values. Apart from these “agreed upon” field names, this type B CGI program makes no assumptions and has no knowledge of any of the other input fields or the input field names or the input field values. If the form html was modified to have a few new fields, but the emailto field was retained, then the type B CGI program would perform execution in exactly the same way for this new form. That is, it would send the email to the value submitted in the emailto field. Thus, a priori knowledge of all fields in the form is not required for the CGI program to perform its function. These arguments are not limited to emailing of form contents, the same arguments apply to other functions performed by CGI programs. For example displaying an html page in response to a submission etc.        Type C: This is a CGI program that does require a priori information about the specific input field names of the form and whose behavior depends on a substantial number of these input fields. However, there is no functional dependence on the submitted field values of any of the fields. In the example in FIG. 1, “form.cgi” would be a type C CGI program if it expected to store the user's input in a database table whose columns matched the fields in the form, namely firstname, smoker, location and id. The same function is performed regardless of the actual values of the submitted form fields. However, if the form was modified to have an extra field such as “Age”, then the same “form.cgi” would not be able to store the user's input for “Age” in the database table because there was no column defined for “Age” in the database table. Thus, “form.cgi” requires a priori information about the fields in the HTML form.        Type D: This is a CGI program that does require a priori information about the specific input field names of the form (like a Type C program described above) and also whose functional behavior depends on the specific submitted field values input by a user during a particular submission. The CGI program needs to have knowledge of the specific field name that asks for the user's input and the user's input further determines a functional behavior of the program. In the example in FIG. 1, “form.cgi” would be a type D CGI program if it examined the value of the user's response to the radio element “smoker” and if the input was “yes”—it responded with “You are wise to not smoke” and if the input was “no”—it responded with “The Surgeon General has determined that smoking may lead to cancer”.        
One of the aspects of this invention is to enable the programmatic creation of CGI programs. A further aspect is to do this with minimal interdependence between the authoring of HTML form and the creation of the CGI program. The HTML form is not constrained in any way with respect to the input fields (their number of type etc) in it. The author of the HTML form does not directly create the CGI program.
At most, he is expected to provide some input to enable the programmatic creation of this CGI program. This input could contain specification of what specific subset of actions should be performed by the CGI program for the specific form instance. The input may or may not contain the html form itself since these actions may or may not depend on the input field elements of the form and may or may not depend on the input field values. Depending on the type of CGI program (A, B, C or D) the following situations may arise:
By definition, a type A CGI program performs a fixed action or set of actions with no dependence on the form field elements. Thus there is no interdependence between the authoring of the form and its associated CGI program. No specification of what action is to be performed by the CGI program needs to be provided since this action is fixed a priori. No knowledge of the specific input fields in the form is required by the CGI program since the action performed is independent of the input fields In the case of Type A CGI programs, the solution may be simple. All forms that would like to avail of the functionality provided by such a CGI program can simply point to its URL in the ACTION tag of the <form> element. Of course, if some other type A CGI program is desired which performs some other (fixed) function then this can also be achieved with no dependence on the form field elements or field values.
In the case of type B CGI programs, the solution may also be simple. The functionality of the type B CGI program is also fixed for all forms. It is the responsibility of the HTML form author to learn about how the CGI program can be customized and insert appropriate directives in the HTML form with input tags of type <hidden> or other input tags. For example, suppose a CGI program performs the function of simply sending by email the user's input provided in the form. The destination address for the email could be specified by the CGI script author as a field in the HTML form with name=emailto. Thus, in the example shown in FIG. 1, the HTML author could add in a field in the HTML form as follows:
<input type=hidden name=emailto value=author@company.com>
When the form is submitted by the user, the CGI program expects a name “emailto” and examines its value to determine the destination for the email. Apart from this agreed upon field, the behavior of the script would be substantially independent of the rest of the form. However, this approach cannot be the full solution because the HTML author should not be expected to learn about the CGI program's specification and to insert these specific tags in the HTML form. Also, not all CGI programs can be constrained to be type A or B.
In the case of type C or type D CGI programs, there has to be some way for the CGI script to learn about the specifics of the input field names and other relevant information in the HTML form. One method may be to have an integrated system where the form is authored and the functions of the CGI program are customized at the same time.
In this scenario, the specification of what actions the CGI program should provide (e.g., where to email the form, or which text file to put it into or how to validate the form fields, etc.) is configured during the authoring of the form. The information on the specific actions may be made available to the CGI program through a configuration file that is available to the CGI program. Another method may be to embed information as comments within the HTML form and make the HTML form file directly available to the CGI program. Thus the CGI program is able to consult the configuration information via a file. When a submission of the form comes in, the CGI program knows what specific functionality is desired from this form.
Another method employed to customize the handling of the form might be to require the author of the form to create the form within a web browser that is interacting with a program that will directly generate the configuration information required for the CGI program.
However, the above methods impose a constraint on the author. It is preferable to not constrain the author to creating the HTML form in any particular front end authoring tool or to visit a web site to create the HTML form. It is preferable to provide the flexibility to the author of the HTML form to create the HTML in any suitable environment that is capable of generating the appropriate HTML for the form, even with the CGI program of type C or type D.